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1. BACKGROUND OF THE INVENTION 

1 . 1 FIELD OF THE INVENTION 

The present invention, relates to programming of electronic data 
carrier applications. In particular, the present invention 
relates to an improved debugging method and system for chipcard 
applications . 

1.2 DESCRIPTION AND DISADVANTAGES OF PRIOR ART 

A new area of technology with increasing importance is 
represented by the increasing use and acceptance of chipcards, 
i.e., so-called SmartCards and their applications for many 
different business purposes. 

Smartcards are intelligent devices having a processor, some 
memory chip and input and output means. For being seriously used 
they have installed a small-dimensioned operating system for 
controlling the operation of one or more business applications 
which are loadable into the memory of the Smartcard. 

In general, it is important to be able to develop new or 
modified chipcard applications. An efficient test facility, a 
quick and comfortable way to correct programming mistakes are 
the main requirements for the commercial success envisaged with 
a chipcard application. 

A modern debugger tool provides for this in general, i.e. , when 
usual computer programs are developed, for example for running 
on a PC on a WINDOWS or a UNIX platform - but not for 
development of chipcard applications . 
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Debugging chipcard applications is much more difficult, instead. 
The reason is the limited comfort programming provisions for 
chipcards and the restricted, particular communication 
providable between chipcard and any respective terminal 
application. Said communication is performed via a serial 
interface, and on a binary, primitive level. 

In particular, any communication between a chipcard and a 
terminal software follows a predetermined, low-level protocol, 
which is quite primitive compared to modern programming 
languages . 

Basically, a master-slave communication is performed, wherein 
the terminal application program is the master and the chipcard 
application is the slave. When running a chipcard application in 
cooperation with the respective terminal application the master 
issues a command wrapped- in in a message-like format, the 
so-called Application Protocol Data Unit - abreviated further 
herein as APDU, sends it to the slave application, and waits for 
response . 

This complicates the debugging and thus an efficient development 
of chipcard applications : 

Those standard communication protocols do not allow to send one 
or more further commands to a chipcard during the processing of 
a current command sent to the chipcard and performed by the 
chipcard application, because any further command may be sent to 
the chipcard after the card response corresponding to the 
current command is received from the card. Said one or more 
intermediate commands, however, are required for collecting 
status information from the chipcard memory in order to explore 
a bug relevant to the processing of said current command. Any 
initiative action originates from the card driver software 
being a part of the card reader device which is addressed by the 
terminal application. Per command issued to the chipcard 
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application only one response can be received from the card. It 
is not possible under said standard protocols to make the card 
issue more than one responses per command. The card is a pure 
and fully restricted slave of the terminal application. 

A prior art chipcard debugger is a software simulation of a 
chipcard which simulate the chipcard in structure and function. 
Thus, a simulation and analysis of the operating system as well 
as the chipcard application is possible, it suffers, however, 
from the basic fact that not the real chipcard but the 
simulation model therof is debugged. Thus, program bugs cannot 
be recognized with 100% probability and in the original runtime 
environment the chipcard application is intended to operate in. 



A variation of this approach is disclosed in French patent 
application no. FR 2 667 419. it shows a hardware simulation, 
i.e., a hardware emulator of the chipcard. Said hardware 
emulator is a hardware device prototyping the structure and 
function of the chipcard as mentioned above. The control of said 
emulator device, - often a particular PC device is used for that 
- is performed by an externally connected standard PC. A 
debugging program is used which is hosted on the external PC. 
The communication between chipcard and terminal application is 
interrupted when a breakpoint is reached. The debug program may 
be used for exploring the status of the chipcard memory. 

The disadvantage, however is the same as mentioned above: The 
chipcard is not tested and debugged under the original runtime 
environment. Thus, no efficient and reliable chipcard 
application development can be provided therewith. 
1 . 3 OBJECTS OF THE INVENT T ON 



It is thus an objective of the present invention to provide a 
method and system which enables for debugging a chipcard 
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application in its real-life runtime environment. 
2 . SUMMARY AND ADVANTAGES OF THE INVENTION 

This objective of the invention is achieved by the features 
stated in enclosed independent claims. Further advantageous 
arrangements and embodiments of the invention are set forth in 
the respective subclaims . 

The present invention is based on the principle to use a 
conventional standard communication protocol between chipcard 
and terminal for debugging purposes as well. Basically, any 
existing prior art communication protocol can be extended by the 
present invention's concepts by inventive extensions which 
provide for the usual debug commands like halt, step, set 
breakpoint at a specified address, reset breakpoint, display 
variable X, set variable X to value a, etc., for use in the 
direct communication between chipcard and terminal. Primarily, 
said extensions are implemented by special commands according to 
a standard protocol, but carrying debug instructions which is, 
however, evaluable by said chipcard application, instead of the 
usual business commands . 

By said debug commands 'hidden' in the standard protocol the 
response behavior of the card is modified: The chipcard 
application processes a chipcard regular (business) command and 
reaches a breakpoint which was set before. Then, the chipcard 
application sends back a response according to the protocol 
requirements in which it tells a % wrapper logic' to have reached 
said breakpoint. The wrapper logic now recognizes due to a 
control information given in the previous command that the 
response comprises debug information and sends it to the debug 
software. Thus, the master/ slave protocol is fulfilled without 
the above mentioned business command having completed. A person- 
controlling the debug software can now setup new debug commands 
for exploring the memory of the chipcard in order to find a bug. 
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The request and the response follows the same principle as 
described before. After issueing a run command the chipcard 
application continues until the next business response has been 
issued by the chipcard application. 

Currently widely used communication protocols, like TO, or Tl 
support for example 4 byte APDUs may be applied. At least one 
bit is now dedicated as a control information, in order to carry 
the information if the APDU is a debug APDU, or an APDU 
comprising regular business information for the terminal 
application or the smartcard application to process. 

A wrapper software for the card driver or a respective modified 
card driver evaluates said control information in each regular 
prior art APDU transported from the chipcard application to the 
terminal. It decides if the APDU contains debug information or 
regular card application business information and feeds the 
respective information content, or the APDU itself to a debug 
control PC, or to the terminal application, respectively. 

The prior art master/slave rules are followed, too. Thus, no 
time-out problems arise in the inventive scheme of operating. 

If desired or useful in any sense, instead. of the control 
information in form a particular return code, any type of 
protocol supplements like channels, etc., can be used as well 
for deciding if a card response comprises debug information or 
not, supposed said supplements are implemented by the card's 
operating system. 

A particular advantage of the present invention is that neither 
terminal application nor the actual chipcard application need to 
be modified, instead, for debugging the wrapper module simply 
has to be loaded into the chipcard. When the application runs 
perfectly the wrapper module will be removed from the chipcard 
which is then ready to be produced in series for public use. 
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Further, the inventive principle can be advantageously applied 
to Programming languages having an Interpreter character as it 
is the JAVA language, for example. 

3 . BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention is illustrated by way of example and is 
not limited by the shape of the figures of the accompanying 
drawings in which: 

Fig. 1 is a schematic illustration showing the essential 
elements of a preferred embodiment of the present 
invention, and 

Fig. 2 is a schematic flow diagram showing the most essential 
steps during the control flow during a debug run of a 
chipcard application according to a preferred 
. embodiment of the inventional method. 

4. DESCRIPTION OF THE PREFERRED EMBODIMENT 

With general reference to the figures and with special reference 
now to fig. 1 a usual standard PC 10 is provided as a 
controlling interface for the developer. A debug control program 
12 is loaded and run for debug purposes . 

Said PC 10 is connected to a chipcard reader 14, as well as a 
terminal 16 having installed a terminal application program 18 
for cooperating with the chipcard application 20 which is 
subjected to the debug process. 

Both programs - debug control 12 and terminal application 18 - 
are logically connected to an inventive wrapping module 22 which 
acts as a wrapper for the conventional card driver used in the 
chipcard reader. 14. Thus, said component 22 acts as an input and 
an output filter for communication from and to the debug program 
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12 and the terminal application 18, respectively. 

Alternatively, instead of the wrapper component 22 a modified 
card driver my be used which comprises equivalent logic 
functions . 

The standard communication protocol - here Tl - is used in a 
double sense. First, between the terminal application 18 and the 
chipcard application 20 as in prior art, and second - according 
to the present inventional embodiment between the debug control 
software 12 and the chipcard application to transport special 
purpose debug commands between the debug control software and 
the chipcard application. 

Some examples for debug commands and responses are illustrated 
next below according to the Tl protocol: 

1. Set breakpoint at address xxyy, and set the special return 
code to '9F01' (in case the breakpoint has reached) 

command: F0 01 00 00 04 xx yy 9F 01 
response : 9000 

2 . Reset breakpoint at address xxyy 
command: F0 02 00 00 02 xx yy 
response: 9000 

3 . Continue execution 
command: F0 03 00 00 0 0 

response: <original response data and return code of the 
interrupted command> 

4. Display variable at address xxyy 

- the command returns the byte value nn 
command: F0 04 00 00 02 xx yy 
response: nn 9000 
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A business command and the corresponding responses is as 
follows : 

1- Command "Mutual Authenticate" 

(this command is used to authenticate the external world to a 
chipcard application, and vice versa) 

command: 00 82 00 xx 10 <16bytes command data> - 
responses: <8bytes response data> 9000 

- indicating successfully execution 

9F01 

- indicating that the breakpoint has been reached 
(according to above example) 

With additional reference how to fig. 2 the essential steps in 
the control flow of the method according to the invent ional 
embodiment are described next below while an exemplary- 
breakpoint is worked on. Most of steps illustrated in the 
drawing are performed by said wrapper program 22 . 

After having loaded the wrapper program for the chipcard driver 
on the PC 10 and the debug control software was started the 
wrapper program waits for receiving an input command (APDU) , 
step 210. 

Then, the application developer enters a debug command 'set 
breakpoint at address xxyy, step 220. 

The wrapper 22 receives and evaluates it. It stores the debug 
flag comprised of the command. In case of said debug command it 
receives the valid value of the debug bit and stores it, step 
230. 

Then the wrapper feeds said command to the original, 'wrapped' 
card driver 14 and by that to the chipcard application, step 
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"240. The card driver stores said breakpoint according to said 
command for address xxyy, step 250, and sends a confirmatory 
response back to the card driver, and thus the wrapper. 

The wrapper evaluates - step 2 60 - its debug flag just stored 
before and recognizes that the answer concerns debug 
information, step 270. As a response always relates to the last 
command received this measure is suffiently reliable to discern 
debug commands from business commands. 

Thus the wrapper is enabled to feed said response APDU generated 
by the card application to the debugging control software 12 - 
see back to fig. 1. if it was a response to a business command 
APDU the wrapper would have fed it to the terminal application 
in order to continue the application regularly, step 290. 

Under the assumption that now a regular - not-debugging command 
is actually issued by the developer basically the same schema as 
illustrated in fig. 2 is followed. The chipcard executes said 
command and continues running until said breakpoint is reached 
which was entered by the developer. 

Now, any memory status information can be requested from the 
chipcard application by issueing debug commands according to the 
above mentioned scheme. Said data can be evaluated and bugs be 
recognized without any timeout problem being present. If desired 
the developer can pause the program and rebegin his work the 
next day. 

On a 'Run* command, finally, and when no more breakpoint being 
present the chipcard application continues and the usual 
business dialog between chipcard application and terminal 
application is followed. 

Thus, according to the inventive principle to hide debug 
commands in regular APDUs and filtering the card responses as 



30-11-2000; 



dfc EP00 126908.3 
- 10 - 



DE9-2000 DESC 



described above the card application can be tested under real 
life conditions as it was mentioned before. 

In the foregoing specification the invention' has been described 
with reference to a specific exemplary embodiment thereof . It 
will, however, be evident that various modifications and changes 
may be made thereto without departing from the broader spirit 
and scope of the invention as set forth in the appended claims . 
The specification and drawings are accordingly to be regarded as 
illustrative rather than in a restrictive sense. 

The present invention can be realized in hardware, software, or 
a combination of hardware and software. A wrapper /debug control 
tool according to the present invention can be realized in a 
centralized fashion in one computer system, or in a distributed 
fashion where different elements" are spread across several 
interconnected computer systems. 

Even the wrapper program module is not necessarily loaded in the . 
chipcard storage itself. It can be externally stored and run as 
well, as long as th econnections are logically correct as 
illustrated herein or a person skilled in the art would 
/•f- connect. Any kind of computer system or other apparatus adapted 
( for carrying out the methods described herein is suited. A 

typical combination of hardware and software could be a general 
- purpose computer system with a debug control program that, when 
J being loaded and executed, controls the computer system such 
'that it carries out the methods described herein. 

/ The present invention can also be embedded in a computer program 
product, which comprises all the features enabling the 

j implementation of the methods described herein, and which - when 
loaded in a computer system - is able to carry out these 
methods . 

*j Computer program means or computer program in the present 
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context mean any expression, in any language, code or notation, 
of a set of instructions intended to cause a system having an 
information processing capability to perform a particular 
function either directly or after either or both of 
the following 

a) conversion to another language, code or notation; 

b) reproduction in a different material form. 
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3 0. Nov. 2000 

1. A method for debugging chipcard applications characterized by 
the step ofusing a chipcard application /terminal application - 
standard communication protocol for transporting (240, 280, 290) 
debug information, which is evaluable by said chipcard 
application, between a chipcard application (20) and a terminal 
application (18) , or between said chipcard application and a 
debug control program (12) . 

2. The method according to claim 1 in which said debug 
information is transported within Application Protocol Data 
Units (APDUs) . 

3. The method according to claim 1 applied to' JAVA cards, and 
filesystem oriented chipcards . 

4. A wrapper program module (22) for cooperation with a chipcard 
driver (14) having program means implemented for performing the 
step of evaluating (230, 260, 270) a debug control information 
for distinguishing between debug information and business 
information . 

5. The wrapper program module according to the preceding claim 
having program means implemented for performing the step 
of feeding (280) a response from a chipcard application (2 0) 
comprising debug information to a debug control program ( 12 ) , 
and feeding (290) regular business information issued by said 
chipcard application to a terminal application (18) 
communicating with the chipcard application, each according to 
an evaluation (260) result (270) . 

6. A chipcard driver program being extended by an implementation 
of the steps performed by the wrapper program module (22) 
according to the two preceding claims. 
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7. A data processing system (10) having installed debug control 
program means (12) for performing the steps of one of the 
methods according to claims 1 to 3 , or, processing debug 
information filtered (270) by a wrapper module (22) according to 
claims 4 or 5, or being processed by a chipcard driver program 
extended according to the preceding claim. 

8. A computer program for execution in a data processing system 
comprising computer program code portions for performing the 
step of the method according to claim 1 to 3 when said computer 
program code portions are executed on a computer. 

9. A computer program product stored on a computer usable medium 
comprising computer readable program means for causing a 
computer to perform the method of one of claims 1 to 3 when said 
computer program product is executed on a computer. 

10. A chipcard having loaded a program which was tested with the 
method of one of the claims 1 to 3 . 
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The present invention relates to programming of electronic data 
carrier applications. In particular, it relates to an improved 
debugging method and system for chipcard applications (20) . It 
is based on the principle to use a conventional standard 
communication protocol between chipcard (20) and terminal 
application (16) for debugging purposes as well. Primarily, 
protocol extensions are implemented by special commands 
according to said standard protocol, but carrying debug 
instructions instead of the usual business commands. A wrapper 
logic (22) wrapping the card driver recognizes due to a control 
information given in the previous command that the response 
comprises debug information and sends it to the debug software 
(12) . (Fig. 1) 
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